Объединение двух существующих простых таблиц может быть более эффективным, чем индексирование данных с нуля, и может быть желательным в некоторых случаях (например, при объединении таблиц «main» и «delta» вместо простого перестроения «main» в схеме разбиения «main+delta»). Поэтому indexer предоставляет опцию для этого. Объединение таблиц обычно происходит быстрее, чем перестроение, но всё же не мгновенно для больших таблиц. По сути, нужно один раз прочитать содержимое обеих таблиц и один раз записать результат. Объединение таблиц размером 100 ГБ и 1 ГБ, например, приведёт к 202 ГБ ввода/вывода (но это всё ещё, вероятно, меньше, чем требуется для индексирования с нуля).

Основной синтаксис команды выглядит следующим образом:

sudo -u manticore indexer --merge DSTINDEX SRCINDEX [--rotate] [--drop-src]

Если не указан параметр --drop-src, затрагивается только таблица DSTINDEX: содержимое SRCINDEX будет в неё объединено.

Параметр --rotate обязателен, если DSTINDEX уже обслуживается searchd.

Типичная практика — объединять небольшой обновлённый набор из SRCINDEX в DSTINDEX. При объединении атрибутов значения из SRCINDEX имеют приоритет, если встречаются одинаковые идентификаторы документов. Однако обратите внимание, что "старые" ключевые слова не будут автоматически удалены в таких случаях. Например, если в DSTINDEX для документа 123 есть ключевое слово "old", а в SRCINDEX для него есть ключевое слово "new", после объединения документ 123 будет найден по обоим ключевым словам. Чтобы исправить это, можно явно указать условие для удаления документов из DSTINDEX; соответствующий параметр — --merge-dst-range:

sudo -u manticore indexer --merge main delta --merge-dst-range deleted 0 0

Этот параметр позволяет применять фильтры к целевой таблице вместе с объединением. Фильтров может быть несколько; для включения документа в итоговую объединённую таблицу должны быть выполнены все условия. В приведённом выше примере фильтр пропускает только те записи, где 'deleted' равен 0, исключая все записи, помеченные как удалённые.

--drop-src включает удаление SRCINDEX после объединения и до поворота таблиц, что важно, если вы указываете DSTINDEX в killlist_target DSTINDEX. Иначе при повороте таблиц документы, объединённые в DSTINDEX, могут быть подавлены SRCINDEX.

При использовании простых таблиц возникает проблема, связанная с необходимостью иметь данные в таблице как можно более свежими.

В этом случае используются одна или несколько вторичных (также известных как дельта) таблиц для захвата измененных данных между временем создания основной таблицы и текущим временем. Измененные данные могут включать новые, обновленные или удаленные документы. Поиск становится поиском по основной таблице и дельта-таблице. Это работает бесшовно, когда вы просто добавляете новые документы в дельта-таблицу, но когда дело доходит до обновленных или удаленных документов, остается следующая проблема.

Если документ присутствует как в основной, так и в дельта-таблице, это может вызвать проблемы во время поиска, так как движок увидит две версии документа и не будет знать, как выбрать правильную. Таким образом, дельта-таблица должна каким-то образом сообщить поиску, что в основной таблице есть удаленные документы, которые следует игнорировать. Для этого и нужны kill-листы.

Таблица может поддерживать список идентификаторов документов, который можно использовать для подавления записей в других таблицах. Эта функция доступна для простых таблиц, использующих источники из базы данных, или простых таблиц, использующих XML-источники. В случае источников из базы данных, источник должен предоставить дополнительный запрос, определенный с помощью sql_query_killlist. Он будет хранить в таблице список документов, который сервер может использовать для удаления документов из других простых таблиц.

Ожидается, что этот запрос вернет ряд строк с одним столбцом, каждая из которых содержит только идентификатор документа.

Во многих случаях запрос представляет собой объединение запроса, который извлекает список обновленных документов, и списка удаленных документов, например:

sql_query_killlist = \
    SELECT id FROM documents WHERE updated_ts>=@last_reindex UNION \
    SELECT id FROM documents_deleted WHERE deleted_ts>=@last_reindex

Простая таблица может содержать директиву killlist_target, которая сообщит серверу, что она может предоставить список идентификаторов документов, которые следует удалить из определенных существующих таблиц. Таблица может использовать либо свои собственные идентификаторы документов в качестве источника для этого списка, либо предоставить отдельный список.

table products {
  killlist_target = main:kl
  path = products
  source = src_base
}

Когда killlist_target указан, kill-лист применяется ко всем перечисленным в нем таблицам при запуске searchd. Если любая из таблиц из killlist_target подвергается ротации, kill-лист повторно применяется к этим таблицам. Когда kill-лист применяется, таблицы, на которые он повлиял, сохраняют эти изменения на диск.

killlist_target имеет 3 режима работы:

1. killlist_target = main:kl. Идентификаторы документов из kill-листа дельта-таблицы подавляются в основной таблице (см. sql_query_killlist).
2. killlist_target = main:id. Все идентификаторы документов из дельта-таблицы подавляются в основной таблице. Kill-лист игнорируется.
3. killlist_target = main. И идентификаторы документов из дельта-таблицы, и ее kill-лист подавляются в основной таблице.

Можно указать несколько целей, разделенных запятыми, например:

killlist_target = table_one:kl,table_two:kl

ALTER TABLE delta KILLLIST_TARGET='new_main_table:kl'

POST /cli -d "
ALTER TABLE delta KILLLIST_TARGET='new_main_table:kl'"